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ABSTRACT 

The  Navy’s  Distance  Support  (DS)  capability1 
combines  people,  processes,  and  technologies 
into  a  collaborative  Fleet  support  infrastructure 
without  geographic  boundaries.  Distance 
Support  remotely  provides  reactive,  proactive, 
and  predictive  support  to  Sailors  and  afloat 
commands  in  logistics,  maintenance  and 
modernization,  supply,  manpower,  personnel, 
training  and  education  (MPTE),  medical,  and 
chaplaincy  support.  The  DS  program  is 
managed  by  the  Sea  Warrior  Program  (PMW 
240)  within  the  Navy  Program  Executive  Office 
for  Enterprise  Information  Systems  (PEO-E1S) 

This  paper  is  intended  to  encourage  discussion 
about  the  state  of  DS  within  the  Navy  Enterprise 
to  help  realize  the  potential  of  DS  to  Reduce 
Total  Ownership  Cost  (R-TOC)  of  both  legacy 
and  new  ship  acquisitions. 

Over  the  past  decade,  the  US  Navy  has 
introduced  the  concept  and  capability  of  DS  to 
the  Navy  Enterprise,  both  ashore  and  afloat. 
What  started  as  disparate  support  centers 
without  a  centralized  call  center  has  slowly 
grown  into  a  two-part  Navy-wide  capability  or 
data  infrastructure  to  enable  people,  processes 
and  technology  that  1 )  supports  the  transition  of 
workload  /  tasks  and  2)  supports  requests  /  help 
from  the  ship  to  shore  infrastructure. 

During  the  past  ten  years  of  growth  and 
improvement  did  implementation  of  DS 
throughout  the  Navy  help  R-TOC?  Elas  DS  yet 
to  fully  enable  viable  reductions  in  ship¬ 
manning,  “Find  Time”  and  the  logistics 
footprint? 


1  CNO  Memorandum  on  Distance  Support  dated  22  March  2007: 

Maximize  the  effectiveness  and  efficiency  of  shore  support  and  facilitate 
shore  infrastructure  reduction  through  knowledge  management, 
technology,  organizational  alignment,  process  standardization  and  optimal 
balance  of  centralization  and  decentralization. 


While  there  is  now  a  more  centralized  DS  call 
center  capability,  structured  process,  and 
improved  technology  to  help  reduce  ship 
manning  and  other  life  cycle  /  total  ownership 
costs,  improvements  could  continue  to  advance 
DS  functional  going  forward. 

INTRODUCTION 

In  1999,  the  Navy  adopted  the  DS  concept  to 
address  the  challenges  associated  with 
establishing  a  smaller,  more  versatile  weapon 
system  population,  reducing  manpower  to 
operate  and  maintain  these  weapon  systems,  R- 
TOC  and  increasing  the  efficiency  and 
effectiveness  of  a  leaner  shore  infrastructure. 

DS  was  recognized  as  a  viable  way  to  use 
information  technology  (IT)  and  connectivity  to 
provide  “reach  back”  and  maintenance  support 
to  Fleet  personnel  as  an  effective  response  to  the 
challenges  described  above. 

Also  in  May  1999,  a  memo  from  the  Under 
Secretary  of  Defense  for  Acquisition, 
Technology  and  Logistics  (USD/AT&L) 
stressed  that  the  purpose  of  R-TOC  is  to 
maintain  or  improve  current  readiness  while 
reducing  Operations  &  Support  (O&S)  costs. 

The  memo  instructed  the  Services  to  focus  on 
three  general  approaches. 

•  Reliability  And  Maintainability  (RAM) 
improvements 

•  Reduction  of  supply  chain  response  time 
and  reduction  of  logistics  footprint 

•  Competitive  product  support. 

DS  can  be  a  key  enabler  for  the  continued  re¬ 
engineering  of  the  support  infrastructure  and  can 
provide  reduction  of  supply  chain  response  time 
and  logistics  footprint;  thus,  providing  program 
managers  (PMs)  with  a  viable  process  to  meet 
the  second  USD/AT&L  R-TOC  approach  cited 


Report  Documentation  Page 


Form  Approved 
OMB  No.  0704-0188 


Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 
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above.  While  supply  chain  cost  reduction  often 
involves  process  changes,  rather  than  new 
technologies,  and  can  be  implemented  without 
significant  investment,  changing  DS  processes 
and  technology  without  careful  consideration  of 
who,  how,  and  why  it  will  be  used  may  negate 
cost  savings  in  the  long  term. 

As  the  DS  community  instituted  various  Navy¬ 
wide  processes  and  technologies,  it  was 
identified  that  a  robust,  modem  GDSC  could  be 
instrumental  in  reducing,  the  “Find  Time” 
(response  time)  (Figure  1  below)  for  problem 
resolution,  whether  system,  equipment  or 
quality  of  life,  resulting  in  R-TOC. 

FIND  TIME  FIX  TIME 

EUs«*ine.  •  icove 
CRM  approach  to  the 
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*rcv*cfcvr  potential 
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tool*  resource*. 

Figure  1  -  DS  Reduces  Total  Response  Time 

(DS  CRM,  Distance  Support  Framework,  MS 
Powerpoint  presentation,  Oct.  2011) 

Re-engineering  the  Navy’s  support 
infrastructure  for  greater  efficiency  and  cost- 
effectiveness  is  ongoing  to  support 
operationally-manned  force  structures  while 
supporting  the  pillars  of  Sea  Power  21 .  New 
acquisitions  are  being  designed  with  integrated 
DS  which  will  be  critical  to  their  success.  Naval 
bases  of  the  future  must  be  configured  to  support 
these  new  ship  classes  and  may  not  resemble 
today’s  organic  and  contractor  industrial 
complexes.  Using  DS  as  a  primary  enabler, 
regional  or  centralized  readiness  centers  should 
be  designed  from  the  bottom  up  to  provide  real 
time  readiness  support  to  the  Fleet. 

Today,  at  its  best,  DS  has  shown  to  improve 
readiness,  reduce  the  logistics  footprint  and 
improve  the  quality  of  service  /  life  provided  to 
Fleet  personnel. 

Yet,  at  its  worst,  DS  labels  have  been  applied  to 
processes  and  applications  pushed  to  the  Fleet 
that  are  work  process  cumbersome,  fail  to  “link” 
data  to  off-ship  support,  and  use  an  inordinate 


share  of  limited  bandwidth.  In  this  use, 
bandwidth  is  essentially  the  quantity  of  data  that 
can  be  transmitted  during  a  fixed  period  of  time. 

A  discussion  of  how  organizations  provide 
online  tools  and  applications  to  the  Fleet  is 
underscored  by  the  Commander,  U.S.  Fleet 
Forces  Command  (USFFC)  blog  comments. 
ADM  Flarvey  wrote,  "...  that  during  his  time  on 
USS  OAK  HILL,  the  crew  candidly  presented  the 
goods,  bads  and  others  on  the  following 
programs  [sic]: 

•  Relational  Administrative  Data 
Management  (R-ADM) 

•  Navy  SKED  [sic] 

•  Electronic  Shift  Operations 
Management  System  (eSOMS) 

•  Transaction  Online  Processing  System 
(TOPS) 

•  Navy  Cash 

•  Training  /  Operational  Information 
Services  (TOR1S) 

•  Training  Figure  of  Merit  (TFOM) 

•  Casualty  Reporting  System  (CASREP) 

•  Defense  Readiness  Reporting  System  - 
Navy  (DRRS-N) 

•  Organizational  Maintenance 
Management  System  -  Next  Generation 
(OMMS-NG)...  ” 

Most,  if  not  all,  of  these  applications  currently 
reside  on  the  Navy  Information  Application 
Product  Suite  (NIAPS)  version  2.3,  which  is  one 
of  the  technology  cornerstones  of  DS.  In 
general,  USFFC  was  able  to  obtain  candid 
feedback  from  Fleet  Sailors  about  their 
“working  level”  perception  of  various  DS 
application’s  capabilities.  This  type  of  feedback 
is  invaluable  since  it  is  at  this  level  DS 
applications  either  help  work  processes  or  don’t. 

The  take-away  from  those  comments  and  others 
like  them  is  that  some  DS  applications  work 
well,  while  others  may  actually  add  work  instead 
of  reduce  work.  One  is  reminded  of  a  quote  by 
Bill  Gates,  co-founder  of  Microsoft  Corporation, 
“The  first  rule  of  any  technology  used  in  a 
business  is  that  automation  applied  to  an 
efficient  operation  will  magnify  the  efficiency. 


The  second  is  that  automation  applied  to  an 
inefficient  operation  will  magnify  the 
inefficiency.”  Unfortunately  some  of  the  DS 
applications  pushed  to  the  Fleet  may  be  in  the 
second  group. 

USFFC  has  taken  direct  steps  to  further  review 
and  improve  the  issues  and  processes  that  led  to 
the  challenges  found  on  USS  OAK  FULL  (LSD- 
51),  e.g.,  Commander,  United  States  Fleet 
Forces  Serial  003  -  Fleet  Sustainment  and 
Commander,  United  States  Fleet  Forces  Serial 
006  -  Transitioning  New  Capabilities  to  the 
Fleet. 

In  the  future,  as  Acquisition  Program  Managers 
and  Principal  Assistant  Program  Managers 
(PAPMs)  learn  to  implement  the  DS  concept 
more  effectively,  it  will  allow  the  Fleet  to 
operate  globally  with  streamlined  and 
operationally-manned  force  structures,  improve 
business  process  efficiency  and  help  reshape  the 
Navy  support  infrastructure,  all  of  which  will 
provide  real  R-TOC. 

Yet,  an  issue  within  the  Navy  that  may  be 
overlooked  is  a  lack  of  common  definition  for 
DS  in  use  by  the  Navy  Enterprise.  A  parable 
from  India  about  blind  men  touching  different 
points  on  an  elephant  best  describes  how  DS 
seems  to  be  perceived  within  the  Navy.  That  is 
not  to  say  they  are  blind  to  the  reality  of  DS,  it  is 
just  that  DS  seen  from  one  perspective  often 
reflects  only  an  understanding  of  DS  in  a  single 
dimension  and  not  as  needed  from  a  global  Fleet 
perspective.  As  personnel  involved  with 
segments  of  Navy  DS  move  positions,  retire,  or 
otherwise  lose  touch  with  DS  developments, 
they  often  maintain  that  single  perspective  of 
DS,  when  actually  DS  has  radically  changed 
over  the  past  10  years  and  continues  to  do  so. 

The  authors  would  propose  the  following 
definitions  and  vision  be  considered  and  used  in 
a  global  sense  when  discussing  DS  within  the 
Navy  Enterprise. 

Definitions 

Distance  Support  is  a  capability  that,  through  a 
combination  of  processes  and  technology, 


delivers  significant  support  to  enable  each 
command  to  operate  at  optimal  capability  in 
support  of  the  command's  mission.  It  provides 
the  Sailor  with  a  single  desktop  point  of  entry  to 
an  integrated  tool  bag  of  processes,  while 
simplifying  access  to  Naval  maintenance, 
technical,  supply,  training,  administrative, 
personnel  resources  and  provides  infrastructure 
or  people-related  support. 

Moving  Work  Ashore  (MW A)  is  not  just  about 
moving  work  ashore,  but  also  the  support 
processes  (help)  ashore.  MW  A  can  be  best 
understood  as  a  “catch  all”  phrase  describing  the 
people,  processes,  and  technology  that  1 ) 
supports  the  transition  of  workload  /  tasks  and  2) 
support  requests  (help)  from  the  ship-to-shore 
infrastructure  and  the  responses  back  that 
completes  the  task.  MWA  is  a  combination  of 
work,  tasks,  and  processes  previously  completed 
aboard  a  platform  or  ship  by  the  crew  and  now 
are  completed  off-platform,  typically  by  shore 
infrastructure  support.  This  work  may  be: 

•  the  completion  of  forms,  reports,  naval 
messages,  (e.g.,  an  enlisted  evaluation,  a 
casualty  report  (CASREP)) 

•  the  compilation  of  data  to  develop  a 
report  (e.g.,  Navy  Energy  Usage 
Reporting  System  (NEURS)),  equipment 
health  data  transfers  (e.g.,  Enterprise 
Remote  Monitoring  System  (eRMS)  or 
Integrated  Condition  Assessment  System 
(ICAS)) 

•  the  accomplishment  of  work  tasking, 
(e.g.,  corrective  or  preventative 
maintenance  actions  performed  under 
Performance-based  Logistics  (PBL)) 

•  or  other  non-organic  support  and  shore- 
based  infrastructure. 

As  DS  continues  to  improve,  the  use  of  the  term 
MWA  may  be  superseded  by  a  better  definition. 
Therefore,  the  reader  is  cautioned  that  using  the 
term  MWA  may  not  fully  describe  the  actual 
process  or  applications  needed  or  used. 

Distance  Support  Moving  Work  Ashore  (DS 
MWA)  as  currently  construed  is  a  combination 
of  MWA  enabled  by  common  DS  transferring  or 
moving  information,  data  or  task  functions  to 


and  from  the  seaffame  and  accomplishment  at  an 
off-platform  location.  This  includes  information 
or  data  that  is  only  available  on  the  platform  that 
must  be  forwarded  to  the  off-ship  and  ashore 
infrastructure  for  work  completion,  usually  via 
applications  residing  on  the  platform,  e.g.,  via 
DDG  1 000  Integrated  Software  Support  Suite 
(IS3),  Navy  Tactical  Command  Support  System 
(NTCSS),  NIAPS  and  information  that  been 
changed  or  updated  by  shore  support  and  is 
needed  by  the  crew  afloat.  In  the  case  of  newer 
ship  classes  like  the  Littoral  Combat  Ships 
(LCS)  and  DDG  1000  Class  Destroyers,  some  of 
the  work,  such  as  preventative  maintenance 
(PM),  predictive  maintenance  and  condition- 
based  maintenance  (CBM),  supply  and  logistics 
functions,  and  some  administrative  actions,  will 
be  partially  or  completely  absorbed  by  the  shore 
infrastructure  requiring  very  little  input  by  the 
crew. 

Distance  Support  Vision 

Guidance  and  policy  indicates  DS  should  be 
viewed  as  the  Fleet’s  principal  readiness  enabler, 
facilitating  timely  technical  assistance, 
knowledge  /  education  tools  and  logistics 
support.  DS  will  help  bring  the  Navy  Career 
Tools  (formally  Sea  Warrior)  application  to  sea, 
remotely  monitor  equipment  health,  improve 
medical  care  and  supply  management, 
streamline  Navy  Continuous  Training 
Environment  (NCTE)  for  Fleet  training  and 
validate  optimally  based  manning  of  new 
systems  and  platforms. 

Sailors  will  use  DS  to  manage  their  careers, 
collaborate  with  subject  matter  experts  and 
access  authoritative  information  in  near  real  time 
wherever  they  are  operating.  Every  Sailor  will 
receive  the  same  experience  regardless  of 
geographic  location. 

As  such,  DS  delivered  to  Fleet  platforms  must 
be  able  to  maximize  the  effectiveness  and 
efficiency  of  shore  support  and  facilitate  shore 
infrastructure  reduction  through  knowledge 
management  (KM),  technology,  organizational 
alignment,  process  standardization  and  optimal 
balance  of  centralization  and  decentralization. 


To  fully  achieve  the  potential  of  DS,  program 
managers  and  process  owners  Navy -wide  will 
require  a  thorough  understanding  and  knowledge 
of  DS  to  effectively  integrate  processes, 
concepts  and  technologies  in  their  Total  Life 
Cycle  Systems  Management  (TLCSM)  if  they 
are  to  realize  R-TOC  resulting  from 
implementation  of  DS. 

At  the  recent  26th  Marine  Machinery  Association 
Annual  Spring  Conference  in  201 1,  Rear 
Admiral  David  Lewis,  Program  Executive 
Officer,  Ships,  Naval  Sea  Systems  Command, 
noted  that  the  Navy’s  success  in  building  and 
maintaining  a  cost-effective  force  of  3 1 3  ships  is 
directly  linked  to  its  success  in  implementing  an 
innovative,  capable  and  cost  effective  DS 
strategy. 

Distance  Support  and  New  Ship 
Acquisition 

Two  ongoing  Navy  acquisition  programs,  the 
LCS  and  the  DDG  1000,  will  rely  heavily  on  DS 
processes  and  applications  to  fully  enable  the 
operational-manning  of  these  ships.  The  recent 
details  learned  about  the  effectiveness  of  DS 
applications  and  processes  to  move  workload 
ashore  can  be  obtained  from  Littoral  Combat 
Ship  (LCS)  Class  lessons  learned. 

Some  of  the  early  lessons  learned  from  LCS  are 
1 )  overly  optimistic  Fleet  expectations  of  near 
real-time  bandwidth,  2)  crews  trying  to  follow 
established  processes  correctly  with  little  or  no 
DS  hands-on  experience,  and  3)  not  having 
established  and  tested  end-to-end  (E2E)  DS 
processes.  Also,  the  lack  of  effective  DS  tools 
and  applications  or  funding  for  the  tools  and 
applications  to  support  MWA  negatively 
impacts  DS  capability. 

The  DDG  1000  Class  of  ships  will  also 
incorporate  new  automated  systems  and 
equipment  functions,  as  well  as,  existing  DS  to 
effectively  move  workload  ashore.  The 
planning  for  DS  to  enable  planned  reductions  in 
crew  size  for  the  DDG  1000,  1001  and  1002  also 
provides  insight  and  lessons  learned  useful  to 
better  developing  Fleet-wide  DS. 


While  it  must  be  remembered  that  there  are 
significant  differences  between  the  DDG  1 000 
and  the  LCS  Class  of  ships,  both  operationally 
and  in  manning,  the  implementation  of  effective 
DS  to  support  the  LCS  Class  of  ships  serves  as  a 
viable  and  relevant  model  for  DS  to  support  the 
DDG  1000  Class,  and  other  planned  ship  classes 
to  follow. 

Where  then  does  the  concept  and  functionality 
of  DS  stand  today,  slightly  over  10-years  after 
the  Navy  adopted  DS  in  1999?  The  following 
section  provides  a  basic  overview  of  key  tenets 
to  help  the  reader  understand  the  current  state  of 
DS. 

NAVY  DISTANCE  SUPPORT 

The  Sea  Warrior  Program  (PMW  240)  manages 
the  Navy’s  Distance  Support,  combining 
processes  and  technologies  with  personnel  to 
provide  a  collaborative  DS  Fleet  support 
infrastructure.  DS  provides  reactive,  proactive, 
and  predictive  support  to  Sailors  and  the  Fleet  to 
enable  support  across  the  pillars  of  Personnel, 
Equipment,  Supply,  Training,  Ordnance, 
Installations  and  Facilities,  Medical  and 
Networks  and  Business  Systems. 

Navy-wide  DS  guidance  is  provided  by  Chief  of 
Naval  Operations  (CNO)  policy  and  the  joint 
Commander,  Naval  Surface  Forces  (CNSF) 
Naval  Sea  Systems  Command  (NAVSEA) 
approved  Top  Level  Requirements  for  DS. 
Distant  Support  Strategy  is  guided  by  those 
policies  and  relies  heavily  on  the  lessons  learned 
for  implementation  Navy-wide. 

There  are  three  major  components  of  DS: 

•  Global  Distance  Support  Community 
(GDSC) 

•  Customer  Relationship  Management 
(CRM) 

•  Navy  Information  Application  Product 
Suite  (NIAPS) 


Distance  Support  Policy  and 
Requirements 

Chief  of  Naval  Operations  (CNO)  Distance 
Support  Policy  of  22  Mar  2007,  states  that  DS 
combines  people,  processes  and  technology  into 
a  collaborative  infrastructure  regardless  of 
geographic  location.  Effective,  reliable  and 
timely  movement  of  information  is  required  to 
enable  DS  capabilities  and  processes.  DS  shall: 

•  Enable  process  improvement 

•  Re-engineer  the  support  infrastructure 
allowing  for  an  efficient  use  of  shore 
based  assets  and  capabilities 

•  Provide  classified  and  unclassified 
information  transfer 

•  Optimize  balance  between  organic  and 
shore  based  support  moving  towards 
regionalized  or  centralized  support 
providers 

•  Achieve  infrastructure  reductions 
through  Knowledge  Management  (KM), 
technology  and  organizational  alignment 

•  Consolidate  help  desk  functions  through 
operation  of  the  GDSC  and  tiered 
Sources  of  Support  (SoS). 

The  Commander,  Naval  Surface  Forces  (CNSF) 

/  Naval  Sea  Systems  Command  (NAVSEA) 
Distance  Support  Letter  of  4  Sep  2007, 
delineates  the  following: 

•  Use  DS  and  NLAPS  for  data  transfer  and 
management 

•  Use  GDSC  Tiered  services  and  CRM  as 
the  single  point  of  entry  for  all  requests. 

•  Continuous  ship  to  shore  connectivity  is 
not  necessary 

•  Enable  support  requests  in  seven  days  or 
less 

•  Enable  emergency  requests  within  48 
hours 

•  Enable  real-time  troubleshooting 

•  Minimize  bandwidth  usage 

•  Minimize  shore  infrastructure 

•  DS  should  extend  the  capabilities  of  the 
operating  forces  by  providing 
distributed  reliability  engineering 
maintenance  support  functions 


•  NIAPS  shall  support  hosting  all 
shipboard  technical  manuals  and 
documents 

•  Application  owners  are  the  life  cycle 
managers  with  full  accountability  and 
responsibility  for  their  applications 
acquisition  and  follow  on  sustainment. 


•  Quality  of  life:  (e.g.,  medical  and 
chaplain  care) 

•  Personnel:  (e.g.,  career,  manpower, 
training,  etc.) 

•  Supply  and  logistics:  (e.g.,  technical 
data,  warranty  service,  ship  maintenance 
scheduling,  etc.) 


COMNAVSURFOR  (CNSF)  and  the  LCS  Class 
Squadron  (LCSRON)  are  working  with  the 
Program  Executive  Office  (PEO)  -  Ships 
programs  for  DDG  1000  (PMS  500),  Littoral 
Combat  Ship  (PMS  501),  the  Naval  Sea  Systems 
Command,  Deputy  Commander  for  Surface 
Warfare  (NAVSEA  21)  and  Space  and  Naval 
Warfare  Systems  Center  (SPAWAR)  to  enhance 
the  DS  systems  of  LCS  and  its  support 
infrastructure  ashore.  DS  is  critical  to  supporting 
minimal  manning  on  LCS  and  both  CNSF  and 
LCSRON  are  pushing  several  DS  initiatives. 
Future  enhancements  to  the  DS  architecture 
supporting  LCS  will  use  the  top  level 
requirements  (TLRs)  the  Surface  Warfare 
Enterprise  (SWE)  has  published  for  DS  on 
surface  force  ships.  These  requirements  focus  on 
the  pillars  of  DS  as  outlined  in  the  CNO’s 
Distance  Support  Policy  memo  from  22  May 
2007. 

Additionally,  CNSF  approved  DDG  1000  Shore 
Support  Specification  of  20  Nov  2007, 

(currently  under  revision),  states  DDG  1000  will 
use  DS  products  to  assist  in  moving  work  to 
shore,  capturing,  measuring  and  reporting 
performance  metrics  and  all  related  support  data. 

Global  Distance  Support  Community 
(GDSC) 

Recognized  by  the  call  center  industry  as  “top  of 
its  class”,  the  GDSC  is  at  the  core  of  the  Navy’s 
DS  capability  providing  Fleet  forces  with  a 
single  entry  point  to  assist  with  problem 
resolution.  The  GDSC  is  the  hub  of  the  shore- 
based  Sources  of  Support  (SoS)  network  and 
provides  Fleet  assistance  in: 

•  Ship  systems:  (e.g.,  hull,  mechanical  and 
electrical  (HM&E)  and  weapons 
systems) 


The  GDSC  is  available  24/7/365  worldwide  and 
provides  accurate  and  timely  support.  If 
personnel  cannot  solve  a  problem  with  organic 
resources,  then,  as  mandated  by  CNO  policy, 
they  will  contact  the  GDSC.  This  network 
provides  access  to  SoS  with  problem  solving 
capability,  regardless  of  complexity  or 
simplicity  of  the  problem.  Contact  with  the 
GDSC  generates  a  Remedy©  Request  (Trouble) 
Ticket  that  is  essential  for  capturing  necessary 
contact  information  and  routing  the  request  to 
the  appropriate  SoS  for  solution,  management 
and  problem  resolution. 

Figure  2  below  shows  a  snapshot  of  the 
September  2011  call  volume  by  category  as  an 
example  of  the  types  of  calls  received  by  the 
GDSC  -  Technical  Call  Center. 


Support  Request  Categories 


Figure  2  -  GDSC  -  Technical  Support  Center 
Request  Categories 

(GDSC  -  Technical  Program  Manager,  Monthly 
Status  Report  for  September  2011,  Sep.  2011) 

Broken  out  by  category,  the  GDSC  -  Technical 
Call  Support  Center  Request  (Trouble)  Tickets 
volume  for  the  month  of  September  2011,  was: 


Subject  ID  Total 

Software  1,800 

Regional  Maintenance  Center 
(RMC)  T ech  Inquiry  1 ,444 

Logistics  Other  238 

Hardware  207 


Documentation  Other 

184 

Feedbacks 

197 

Quality  Of  Life  (QoL) 

61 

Directory  Assistance 

41 

Support  Other 

18 

Medical,  Manning,  Training 

16 

PMS  Other 

2 

Total 

4,208 

There  are  three  GDSC  Call  Centers,  each 
focused  on  their  specific  area  of  expertise:  1) 
GDSC  -  Technical  Support,  2)  GDSC  - 
MPT&E  Support,  and  3)  GDSC  -  Logistics 
Support.  Each  GDSC  Call  Center  will  have 
similar  data  for  the  call  volume  processed  within 
their  area  of  expertise. 

Distance  Support  Customer  Relationship 
Management  (CRM) 

In  its  simplest  form,  Customer  Relationship 
Management  (CRM)  is  the  manner  in  which  the 
Navy’s  shore  infrastructure  manages  their 
interactions  with  their  customers  regardless  of 
customer  location  (i.e.,  ashore  or  afloat). 

DS  CRM  is  both  a  process  and  a  toolset 
providing  conduits-of-connectivity  to  and  from 
the  customer  via  a  workflow  process.  The 
process  includes  the  tracking  of  Support 
Requests  across  the  entire  collaborative  shore 
infrastructure  supported  by  an  information 
repository.  The  repository  is  tied  to  a  business 
analytics  and  a  predictive  knowledge 
management  (KM)  component.  This  component 
serves  to  reduce  the  “Find  Time”  when 
rendering  assistance. 

Successful  DS  CRM  solutions  depend  on  the 
expertise  of  the  particular  GDSC  support 
provider  (i.e.,  Technical,  Supply,  or  Manpower, 
Personnel,  Training  &  Education  (MPT&E)), 
and  SoS  Subject  Matter  Experts  (SMEs),  to 
interact  with  customers  through  any  channel 
chosen  (i.e.,  message,  email,  phone,  chat,  walk- 
in)  as  well  as  a  way  to  track  and  maintain  real¬ 
time  records  of  customer  interactions  for  metrics 
(Figure  3).  These  metrics  provide  both  CRM 
management  and  end-users  a  complete  view  of 
customer  requirements,  needs  and  behaviors 
during  interaction  within  the  DS  infrastructure 


and  allows  the  Navy  Enteiprises  and  DS  shore 
infrastructure  to  better  serve  end  users.  Effective 
DS  CRM  delivers  personalized  and  informed 
service  on-demand. 


Figure  3  -  Distance  Support  Framework 

(DS  CRM,  Distance  Support  Framework,  Oct.  201 1) 


FUNCTIONAL  DISTANCE  SUPPORT 
PRODUCTS  AND  INFRASTRUCTURE 

The  Navy  DS  Program  was  established  in 
August  1999  with  the  stand-up  of  the  GDSC,  a 
24/7/365  Tier  1  help  desk  through  a 
collaborative  agreement  between  NAVSEA, 
NAVSUP,  SPAWAR  and  the  Fleet 
Commanders.  From  August  2000  to  present, 
efforts  have  centered  on  the  establishment  of  a 
collaborative  support  infrastructure  and  common 
CRM  solutions  to  support  request 
documentation  and  tracking.  This  CRM  system 
is  designed  to  include  workflow  management, 
and  provide  a  shared  data  and  metrics 
environment  for  process,  product  and  service 
improvement  for  Fleet  Support  and  readiness. 

The  CRM  software  selected  by  PMW240,  is 
Remedy©,  a  Commercial  Off-The-Shelf 
(COTS)  configurable  software.  Remedy®  was 
the  Functional  Area  Manager  (FAM)  Business 
Case  Analysis  (BCA)  solution,  as  well  as  the 
highest  rated  by  Gartner  Incorporated,  an 
information  technology  research  and  advisory 
firm. 


To  execute  the  Navy’s  DS  CRM  Strategy,  a 
Shared  Data  Environment  (SDE)  was  created. 
Use  of  a  DS  SDE  implies  at  least  a  common 
business  culture  where  information  is  shared  and 
managed  via  the  Remedy©  Request  (Trouble) 
Ticket  generated  by  the  SoS.  This  allows  all 
Navy  commands  to  use  same  business  rule 
terminology,  gain  visibility  and  ultimately 
become  more  productive  and  efficient.  Over 
time  better  cooperation  among  Navy  commands 
has  led  to  the  development  of  an  enterprise-wide 
CRM  that  serves  a  wider  Navy  audience  and 
measurably  improves  day-to-day  Navy  business. 

ENTERPRISE  CUSTOMER  RELATIONSHIP 
MAN  A  GEMENT  (eCRM) 

The  enterprise  CRM  (eCRM)  component  of  DS 
is  a  major  part  of  the  GDSC  capability.  eCRM 
provides  key  applications,  shared  data, 
resolution  tracking,  and  ad  hoc  support 
capabilities,  focusing  on  consolidation  of  all 
Navy  support  request  data  into  a  single,  robust, 
enterprise  system  that  can  aggregate  information 
and  bring  support  visibility  to  key  command 
personnel.  DS  eCRM  metrics  allow  all 
commands  and  SoS  participating  in  the  SDE  to 
gain  insight  into  performance,  volumetric,  and 
functional  areas  associated  with  documented 
support  requests. 

Together,  the  eCRM  and  SDE  yield  millions  of 
records  in  a  considerable  base  of  episodic  data 
from  which  KM  technologies  can  harvest 
decision-enabling  information.  In  this  way,  the 
Navy  DS  approach  is  holistic;  it  captures  and 
stores  data  from  across  the  spectrum  of  the 
Defense  Readiness  Reporting  System  -  Navy 
(DRRS-N)  categories  to  identify  and  mitigate 
factors  contributing  to  readiness  shortfalls.  The 
SDE  integrates  selective  data  from  authoritative 
Navy  sources  so  that  a  problem  or  issue  is  well 
defined.  In  total,  DS  KM  initiatives  are 
improving  both  the  effectiveness  and  efficiency 
of  shore  support  resources  through  a  more 
analytical  use  of  information. 

DS  KM  also  complements  program  metrics  in 
providing  decision  enabling  information  and 
potentially  mitigating  systemic  issues  across  the 
Navy  Enterprise.  However,  the  challenge  of 


effective  DS  KM  is  to  capture  and  promulgate 
not  only  explicit  knowledge  or  “know-what” 
generated  by  transactions  within  the  GDSC,  but 
also  the  tacit  knowledge  or  “know-how”  gained 
through  the  process  of  trouble  or  issue 
resolution. 


The  DS  CRM,  SDE,  SoS  Network: 

•  Is  an  integrated  shore  infrastructure 
solution  providing  single  multi-channel 
point  of  entry  for  Fleet  reach-back 

•  Is  the  DS  system  that  provides 
assignment,  tracking  and  timely 
resolution  of  Fleet  generated  requests 
for  any  assistance 

•  Provides  a  uniform,  automated  process 
(standardized  priority  system)  with  a 
guaranteed  response  time  for  user 
issues. 

The  eCRM  solution  provides  a  central  help  desk 
server  from  which  activities  can  either  enter 
trouble  tickets  directly  into  Remedy©  via  the 
Web  (thereby  eliminating  their  need  for  a 
separate  Remedy©  server)  or  interface  core  data 
elements  (as  defined  by  the  help  desk  working 
group).  eCRM  includes  enterprise  design  and 
support,  licensing,  re -hosting  support  and  server 
administration. 

SoS  POLICY / BUSINESS  RULES 

DS  policy  and  business  rules  are  established  to 
maximize  efficiencies  and  increase  productivity 
while  codifying  a  repeatable  and  uniform 
process  for  handling  customer  requests  in  a 
timely  and  efficient  manner.  The  DS  rules  are 
reviewed  on  a  regular  basis  by  personnel  from 
the  DS  SoS  infrastructure. 

DS  SoS  business  rules  are  composed  of: 

•  Remedy©  operation  and  configuration 
management 

•  Support  request  transactions 

•  Reports 

•  Customer  follow-up 

•  SoS  working  hours 

•  Threat-driven  DS  operations 


•  SoS  Matrix  use  /  maintenance 

•  Unit  table  maintenance 

•  Remedy©  Distributed  Server  Option 
(DSO)  installation  and  test 

•  SoS  technical  business  rules. 

SoS  policy  and  business  rules  allow  the  GDSC 
to  achieve  and  ensure  effective  Navy  DS  CRM. 
The  formation  of  SoS-accepted  and  ratified 
business  rules  helps  the  ongoing  process  of 
consolidating  and  streamlining  the  nearly  800 
Navy  call  centers,  help  desks,  support  centers 
and  customer  support  functions,  many  of  which 
duplicate  efforts  and  do  not  share  data,  into  a 
seamless  GDSC  for  the  Navy  Enterprise. 

Programs  that  use  DS  to  deliver  afloat  assistance 
to  legacy  ships  as  well  as  ships  manned  with 
lean  crews  (e.g.,  LCS  and  DDG  1000)  will  need 
to  ensure  the  GDSC  has  the  most  current 
platform-specific  SoS  Matrix  data  that  the  ships’ 
crews  and  shore  support  infrastructure  need.  All 
applicable  Memoranda  of  Understanding 
(MOUs)  between  program  offices,  applicable 
private  contractors,  and  shore  support 
infrastructure  will  need  to  be  drafted  and 
implemented  by  those  program  offices  in  order 
for  effective  DS  via  the  GDSC  eCRM  structure. 

NAVYDS  METRICS  REPORT 

Based  on  the  features  provided  earlier  in  DS 
development,  a  capability  is  provided  to  display 
Remedy©  Request  (Trouble)  Ticket  data  for 
metric  review  and  analysis  by  commands  and 
other  organizations.  The  DS  CRM  team  provides 
a  standard  metrics  report  based  on  Fleet  criteria, 
as  well  as  the  capability  to  develop  custom 
reports  to  end-users. 

Distance  Support  Navy  Information 
Application  Product  Suite  (NIAPS) 

Bandwidth  is  a  major  limitation  to  Internet 
access  from  deployed  ships.  One  requirement 
for  NIAPS  development  was  to  address  and 
resolve  bandwidth  limitation  issues.  NLAPS 
embeds  critical  applications  and  data  locally  on 
ship  networks.  This  is  important  to  the  Fleet 
because  it  is  faster  and  less  expensive  than 


increasing  external  bandwidth  and  satellite  time 
for  off-ship  access  while  deployed  (see  Figure  4 
below). 

Currently  232  Navy  platforms  use  NIAPS, 
which  fully  supports  both  classified  and 
unclassified  data  and  information  via  processes 
on  either  the  Secret  Internet  Protocol  Router 
Network  (SIPRNet)  or  Non-Classified  Internet 
Protocol  Router  Network  (NIPRNet). 


NIAPS:  Performance  without  the  Internet 
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NIAPS  Afloat 

■  Various  tools  /  applications  reside 

Satellite  Connection  Qn  N|Ap$ 

-OR'  .  ■  Underway, Sailors  use  NIAPS  not 

-pier  Connection  \  the  |nternet 


NIAPS  Ashore 
■  Compresses  data,  then 
replicates  changes  shore-to-ship 
and  ship-to-shore 


Figure  4  -  NIAPS  Data  Paths 

(PMW  240 ,  Fact  Sheet  Distance  Support,  Oct.  2011 ) 

On  FCS  and  legacy  ships,  NIAPS  is  installed  on 
the  ship’s  existing  server,  which  provides  a 
Web-based  information  system  used  to  support, 
distribute  and  collect  information  that  exists  in 
the  legacy,  FCS  IT -21  shipboard  environment. 
This  system  hosts  an  intranet  that  maintains 
information  such  as:  training  courses, 
maintenance  documents  and  maintenance  data 
collection,  as  well  as  business  support. 

On  DDG  1000  Class  ships,  the  method  by  which 
NIAPS  is  installed  is  a  significant  departure 
from  current  Fleet  installations.  On  DDG  1000 
ships,  installation  of  NIAPS  and  other 
applications  such  as  the  Naval  Tactical 
Command  Support  System  (NTCSS),  etc.,  do 
not  require  additional  application-specific  server 
hardware.  Instead,  products  such  as  NIAPS,  and 
NTCSS  will  be  embedded  (wrapped)  within  the 
Total  Ship  Computing  Environment 
Infrastructure  (TSCEI),  Integrated  Software 
Support  Suite  (IS3)  infrastructure  (and  loaded  on 
DDG  1000  TSCEI/IS3  blade  servers).  IS3  and 


embedded  DS  systems  within  DDG  1000  TSCE1 
will  provide  the  capability  to  process  data, 
transfer  data,  and  run  application  software 
solutions  in  support  of  the  ship  and  crew. 

N1APS  version  2.3  currently  comprises  more 
than  40  applications  and  databases  launched 
from  a  single  DS  portal  and  runs  applications 
specifically  tailored  to  individual  afloat  units  for 
training,  career  management,  maintenance, 
technical  drawings,  logistics,  human  resources 
and  morale  and  welfare  support.  These 
applications  are  produced  by  more  than  20 
different  Navy  functional  organizations. 

Keeping  these  applications  operationally 
available  for  the  crew  is  a  challenge,  both  for  the 
organic  and  shore  support  N1APS  IT  teams. 

Examples  applications  on  N1APS  include: 

■  Navy  Knowledge  Online  (NKO) 

■  Surface  Warfare  Officer  Schools 
Command  (SWOS)  or  individual  training 

■  Advanced  Technical  Information  System 
(AT1S)  for  technical  documentation, 

-  PMS  Scheduling  (SKED) 

■  Food  Service  Management  (FSM3). 

For  morale  and  welfare  support,  local  web 
content  includes  a  DS  website  (formally  the 
Navy  AnchorDesk),  NKO,  and  information  from 
the  Bureau  of  Personnel  (BUPERS). 

The  NLAPS  local  suite  provides  information  to 
users  during  times  when  networking  external  to 
the  ship  is  unavailable.  When  the  ship  has 
network  connectivity  with  shore,  amendments 
(updates)  to  the  content  can  be  obtained  through 
the  NLAPS  Global  Amendment  Servers  which 
are  currently  hosted  at  the  Naval  Surface 
Warfare  Center  (NSWC)  Crane  Division,  Crane, 
IN.  NLAPS  amendments  are  comprised  of 
changes  to  web  based  content,  training 
materials,  ship  manuals,  technical  drawings, 
human  resource  data  and  other  data  intended  to 
reside  on  ship  installed  NLAPS.  Basically, 
amendments  are  highly  compressed  files  that  are 
only  readable  by  the  deployed  N1APS  systems. 
Data  replication  is  implemented  through  the  use 
of  software  residing  on  N1APS  to  generate 
replicated  files  which  are  transferred  from  ship- 
to-shore  and  shore -to-ship  automatically  or 


manually.  This  process  enables  limited  b/w 
data  replication  from  ship-to-shore  and  shore-to- 
ship. 

NIAPS  APPLICA  TIONS 

N1APS  is  a  result  of  the  Joint  Distance  and 
Response  (JDSR)  Advanced  Concept 
Technology  Demonstration  (ACTD)  team 
concept  to  provide  timely  access  to  national, 
global  subject  matter  experts  (SMEs)  and 
knowledge  to  the  warfighter  and  maintainer,  in 
addition  to,  providing  a  telecommunications 
platform  for  remote  diagnostic  support,  help 
desk  operations,  condition  and  case-based 
maintenance,  collaboration,  and  interactive 
electronic  technical  manuals  (TMs).  The  JDSR 
ACTD  efforts  resulted  in  a  coordinated  process 
for  non-tactical  application,  content  selection  for 
deployment,  including  software  and  hardware 
licenses,  standardized  training  resources, 
meeting  of  logistics  requirements  and  help  desk 
integration  with  the  GDSC,  which  ultimately 
became  known  as  NIAPS. 

NIAPS  version  2.3  is  the  predominant  version  in 
the  Fleet  today.  This  version  provides: 

1 )  products  to  deliver  directory  services,  e- 
mail,  Web  acceleration,  office  automation 
applications,  collaboration  tools  and 
antivirus  software 

2)  the  NIAPS  software  framework  providing 
support  programs,  code  libraries,  a  scripting 
language  to  help  develop  and  integrate  the 
different  components 

3)  the  Program  of  Record  (PoR)  applications 
described  earlier  in  this  paper. 

As  described,  the  DS  functionality  contained 
within  NIAPS  is  defined  in  large  part  by  the 
PoR  applications. 

As  of  the  writing  of  this  paper,  NIAPS  version 
2.4  is  entering  code  lock-down  with  a  planned 
release  in  mid-2012  with  planned  Fleet  upgrades 
beginning  shortly  thereafter. 

Because  DS  CRM  and  NIAPS  are  key  enablers 
for  delivering  afloat  assistance  to  the  legacy 
Fleet  assets,  these  capabilities  are  being 
introduced  to  most  new  construction  platforms 


in  some  form.  These  range  from  a  basic  level  of 
GDSC  call  requests  for  help,  to  applications  and 
processes  specifically  designed  to  move  or 
reduce  workload,  and  capturing  and  transmitting 
health  status  of  equipment  and  systems.  As 
discussed  above  in  previous  sections,  two  new 
ship  classes  that  are  and  will  use  DS  to 
significantly  reduce  manning  requirements  for 
R-TOC  are  the  LCS  and  DDG1000  ships. 

Both  of  these  ship  classes  have  incorporated  DS 
as  part  of  the  design  concept  for  their  operation 
and  are  discussed  more  in  the  following 
sections. 

LITTORAL  COMBAT  SHIP 
(LCS)  DISTANCE  SUPPORT 

The  LCS  warship  concept  requires  new 
processes  that  will  serve  as  a  model  for  future 
fleet  operations.  The  LCS  is  a  fast,  agile  and 
networked  surface  combatant  that  provides 
capabilities  and  flexibility  to  US  maritime 
dominance  now  and  into  the  future.  The  LCS 
will  operate  with  mission  packages  that  are 
loaded  on  the  seaframe  to  execute  missions  as 
assigned  by  commanders.  These  mission 
packages  focus  on  three  areas  of  littoral  threat: 
Anti-Submarine  Warfare  (ASW),  Mine  Warfare 
(M1W)  and  Surface  Warfare  (SUW).  There  is 
also  the  SUW  Maritime  Security  Operations 
(MSO)  mission  package  capability  to  counter  a 
more  global  threat. 

LCS  crews  depend  on  DS  because  the  ship’s 
force  is  dramatically  smaller  in  size  than  those 
on  legacy  ships.  The  LCS  ship’s  small  40-man 
crew  is  focused  on  performing  multiple  roles  to 
accomplish  the  ship’s  mission,  and  therefore  has 
very  little  maintenance  and  administrative  role 
during  deployment.  This  operational  paradigm 
shift  required  development  of  new  processes  and 
applications  to  meet  ship  mission  requirements, 
many  of  these  processes  and  applications  have  a 
DS  enabling  element. 


LCS  Wholeness  Concept  of  Operations 
(CONOPS) 

A  significant  challenge  facing  the  LCS  and  other 
legacy  ships  is  capability  and  availability  of 
bandwidth  for  DS  applications  to  ensure  the 
requisite  reach-back  exists  to  support  the 
minimum  manned  crew.  Solutions  to  these 
challenges  are  captured  in  the  LCS  Wholeness 
Concept  of  Operations,  Revision  C  (CONOPS) 

The  CONOPS  states,  “Minimal  shipboard 
manning  presents  significant  challenges  to  a 
ship  crew’s  ability  to  effectively  accomplish 
traditional  supply  and  maintenance  workload 
afloat.  The  key  enablers  that  will  allow  LCS 
minimally  manned  platforms  to  succeed  will  be 
maximizing  the  efficiencies  created  by  DS  and 
effectively  developing  more  refined  processes 
that  transfer  workload  ashore.  ”  And, 
“Maintaining  threshold  manning  levels  without 
burdening  the  crew  with  excessive  workload, 
losing  capability,  impacting  safety,  creating 
excessive  new  shore  support  infrastructure, 
over-taxing  the  personnel  distribution  process 
or  negatively  impacting  other  Fleet  operational 
assets.  Standard  Operating  Procedures  (SOPs) 
and  information  technology >  solutions  must  be 
developed  to  ensure  the  proper  level  of  DS  to 
minimize  the  administrative  burden  and  allow 
the  crew  to  concentrate  on  operations.  ”  As  can 
be  surmised,  LCSRON  is  addressing  areas 
within  the  implementation  of  DS  that  were 
originally  either  overlooked  or  not  emphasized 
in  the  LCS  planned  design. 

For  the  LCS  to  operate,  a  number  of 
assumptions  are  made  and  articulated  in  this 
CONOPS.  As  needed  DS  processes  were 
evaluated  for  LCS,  the  teams  found  that 
collateral  and  most  administrative  duties  could 
not  be  performed  remotely  to  support  shipboard 
personnel  using  available  DS  application 
formats.  For  DS  to  be  leveraged  for  collateral 
and  administrative  duties  those  applications 
must  be  re-evaluated  and  in  some  cases 
upgraded.  It  is  also  critical  for  successful  DS 
implementation  to  have  Standard  Operating 
Procedures  (SOPs)  developed  and  tested  End-to- 


End  (E2E)  for  each  of  the  processes  used  to 
move  work  ashore  in  support  of  the  crews. 

For  LCS,  developing  new  shore  based  DS 
technical  capabilities  and  operating  procedures 
are  required  for  success  of  the  transformational 
LCS  concepts  of  minimal  manning  and  multi- 
crewing.  DS  applications,  processes  and 
capabilities  must  expand  in  a  collaborative 
manner  as  the  Navy  explores  alternatives  to 
operate  ships  with  fewer  Sailors  and  improve 
business  process  efficiency. 

Two  drivers  for  implementing  DS  for  the  LCS 
will  be  the  Maritime  Support  Detachment 
(MSD)  and  the  Immediate  Superior  in 
Command  (1S1C),  with  the  1S1C  as  overall 
coordinator  and  top-level  decision  maker. 
(Author’s  Note:  Recent  changes  in  the  Navy 
shore  infrastructure  may  supersede  the  MSD 
and  ISIC  concept  as  discussed  in  this  paper.) 
As  conceptualized,  the  MSD  will  be  the  central 
cog  in  the  sustainment  support  infrastructure 
ashore  and  be  available  to  provide  both  routine 
and  urgent  support  to  forces  afloat. 

In  order  to  support  LCS  administration  via  DS,  a 
full  service  administrative  detachment  was 
formed  using  the  existing  Personnel  Support 
Detachment  (PSD)  Afloat  (formerly  known  as 
Pay  and  Personnel  Ashore  (PAPA))  process. 
While  the  current  process  used  by  the  PSD 
Afloat  offers  excellent  support  for  pay  and 
personnel  administration,  it  does  not  completely 
replace  a  ship’s  office,  because  its  services  do 
not  include  career  counselor  administration, 
maintaining  instructions  and  notices,  processing 
general  ship’s  secretary  correspondence, 
processing  legal  paperwork,  etc.  Therefore,  a 
more  robust  organization  was  developed  within 
the  LCS  CLASSRON  organizational  structure  to 
support  legal  admin,  postal  and  career 
counseling  paper  work  and  to  process  routine 
administration  normally  conducted  onboard  a 
ship  with  a  goal  of  removing  all  of  these 
functions  from  the  ship. 

One  of  the  issues  that  challenge  those  in  the 
Navy  and  specifically  ship  classes  like  the  LCS 
and  DDG  1000  is  putting  valid  and  realistic  DS 
placeholders  in  a  new  ship  design.  During  the 


acquisition  design  phases,  without  first 
understanding  what  DS  is  currently  available, 
what  capability  that  DS  actually  has  in  relation 
to  MWA  and  whether  the  DS  capability  is  fully 
funded  for  development  and  delivery  in  a 
timeframe  needed,  and  as  seen  with  the  LCS 
delivery,  can  lead  to  significant  challenges  to 
both  the  program  and  the  ship’s  crew. 

While  several  applications  reside  on  NIAPS  to 
“handle”  the  functions  and  many  previously 
considered  them  DS  applications  (some  still  do), 
the  reality  found  by  the  LCS  team  was  actual 
functionality  of  the  applications  did  not  support 
DS  MWA  processes. 

There  are  applications  currently  being  fielded 
that  are  supposed  to  reduce  and  move  work 
ashore  via  DS,  yet  in  reality,  the  applications’ 
processes  will  not  move  needed  data  without 
manual  intervention.  For  example,  when 
approximately  60  NIAPS  Work  Transport 
Applications  were  analyzed  to  enable  MWA  for 
LCS  approximately  25  percent  of  them  actually 
moved  work  processes  ashore.  Several 
applications  had  to  be  developed  solely  for  LCS, 
because  the  existing  DS  applications  necessary 
to  allow  reduced  manning  did  not  actually  move 
workload  ashore  or  would  not  be  available  in 
time  to  meet  LCS  delivery  to  the  Fleet. 

As  stated  in  the  LCS  Wholeness  CONOPS, 

“The  key  enabler  to  LCS  logistics  success  will 
be  maximization  of  efficiencies  created  by  DS 
and  the  development  of  processes  that  effectively 
transfer  workload  ashore.  ”  Applications  that 
are  work  cumbersome  or  require  manual 
intervention  will  not  meet  the  LCS  or  other 
optimally  manned  ship’s  DS  requirements. 

Since  DDG  1000  will  also  be  dependent  on  DS, 
as  well  as  new  automated  system  and  equipment 
functions  to  enable  the  120-man  crew  to 
effectively  carry  out  the  ship’s  missions, 
incorporating  lessons  learned  from  the 
development  and  successful  fielding  of  LCS  will 
be  important. 


ZUMWALT  CLASS  DISTANCE 
SUPPORT 

Incorporating  Human  Systems  Integration  (HSI) 
from  the  initial  design  stages,  the  ZUMWALT 
Class  Destroyer  program,  unlike  previous  ship 
acquisition  programs,  is  the  first  major 
combatant  to  have  an  explicit  Key  Performance 
Parameter  (KPP)  for  Manpower. 

DDG  1000’s  overall  maintenance  workload  was 
reduced  relative  to  legacy  seaframes  and 
platforms,  through  use  of  advanced  ship 
equipment  and  systems  technologies,  systematic 
maintenance  planning  and  analysis.  The  DDG 
1 000  program  intends  to  incorporate  and 
leverage  LCS,  other  program  DS  lessons 
learned,  and  the  evolving  waterfront  support 
infrastructure  into  upfront  planning  to  better 
transition  the  ship  class  to  the  Fleet.  Since  the 
DDG  1000  operational-manning  concept  is  very 
different  than  that  of  the  LCS  transformational 
concepts  for  minimal-manning  and  multi- 
crewing,  developing  new  shore  based  DS 
technical  capabilities  and  operating  procedures 
is  not  as  critical  and  the  current  planning  is  to 
leverage  either  existing  or  LCS  developed  shore 
support  to  keep  Operational  &  Sustainment 
(O&S)  costs  controlled. 

Shore  Integration 

DDG  1 000  will  use  the  existing  shore 
infrastructure  and  SoS  wherever  economically 
and  operationally  beneficial,  yet  there  are  some 
instances  wherein  the  introduction  of  this  ship 
class  imposes  additional  requirements  upon  the 
existing  shore  support  system.  Although,  as  the 
DDG  1 000  program  matures,  there  may  be 
instances  where  new  areas  of  Fleet  and  Shore 
DS  infrastructure  need  is  identified  and  support 
development  is  required.  The  DDG  1 000 
concept  of  operational-manning  necessitates 
workload  migration  ashore  of  preventive  and 
corrective  maintenance  with  periodicities  greater 
than  90  days,  as  well  as  other  legacy  ship 
functions.  Use  and  implementation  of  the  US 
Navy’s  DS  infrastructure,  policies,  applications 
and  processes  will  be  required  to  provide  the 
required  support  to  DDG  1000.  DS  will  provide, 


in  large  part,  the  enabling  mechanism  and 
processes  to  interact  with  required  shore 
infrastructure  needed  to  provide  the  necessary 
support  in  the  areas  of  maintenance,  training, 
logistics  and  manpower  and  personnel. 

As  mentioned  above,  lessons  learned  from  DS 
implementation  on  the  LCS  show  many  of  the 
DS  applications  presumed  to  help  move 
workload  ashore  actually  did  not  provide  MWA 
or  are  not  available  to  the  ship  when  needed  for 
delivery.  In  the  next  few  years,  the  first  of  the 
ZUMWALT  Class  will  be  delivered  to  the  Fleet. 
However,  funding  constraints  may  impact  the 
the  ability  of  DS  applications  to  keep  pace  with 
this  new  ship  class  requirements,  indicating  a 
historical  repeat  of  the  issues  faced  by  DS 
implementation  on  LCS. 

Ship  Integration 

Meeting  the  DDG  1 000  KPP  for  operationally- 
driven  manning,  the  ship’s  crew  DS  is  enabled 
by  three  levels  or  layers  of  Information 
Technology  (IT)  infrastructure  that  minimize, 
automate  or  moves  work  and  task  processes. 
First  of  these  is  the  ship-wide  TSCEI;  second, 
embedded  within  this  TSCEI  ship-wide  network 
core  is  the  IS3;  and  finally,  wrapped  within  this 
IS3  software  are  the  multiple  DS  related  PoR 
applications.  These  may  be  embedded  in  suites 
of  software  applications  like  NIAPS,  NTCSS,  in 
stand-alone  PoR  applications  or  in  Web-based 
stand  alone  PoR  applications. 

Lessons  learned  from  the  implementation  and 
use  of  DS  within  the  operational  design  of  new 
ship  classes  will  provide  validation  of  DS 
processes  and  technology  useful  for  future 
platform  acquisitions,  like  the  CV(X)  and 
CG(X)  and  others.  Yet  will  DS,  as  currently 
used  and  delivered  in  the  Fleet,  provide 
improved  cost  savings  that  can  be  realized?  The 
following  section  raises  some  points  the  authors 
believe  should  be  discussed  widely  throughout 
the  Navy  Enterprise. 


DISTANCE  SUPPORT  COST 
SAVINGS 

A  recent  paper  by  Nicolas  Guertin,  PEO-1WS 
and  Paul  Bruhns,  ManTech  International  Corp., 
“Comparing  Acquisition  Strategies: 
Maintenance  Free  Operating  Period  (MFOP)  vs. 
Traditional  Fogistics  Support”  contained  some 
interesting  data  about  cost  savings  realized 
through  the  use  of  DS.  In  their  discussion  of 
implementing  MFOP  for  existing  systems  in  a 
stepwise  manner,  they  state,  “The  first  step  is  to 
capture  the  value  of  distance  support  from  ship 
to  shore  through  a  network  connection  that 
bridges  between  the  organic  system  maintainers 
(O)  to  intermediate  subject  matter  experts  and 
tech  assist  (I)  levels.  This  O-to-I  Level 
Maintenance  Bridge  requires  little  product 
integration  and  will  immediately  generate  cost 
savings.  The  table  below  highlights  an  example 
program  that  achieved  a  15:1  cost  savings  ratio 
when  employing  distance  support  services  over- 
deploying  tech  assets: 

FLEET  Tech  Assist  Data  for  Submarine  Enterprise 
120  FTA  Events  Performed 

93  Loca I  (Norfol k) 

27  Out-Of-Area 

100%  Distance  Support  (DS)  Attempts  (CFFC/Command  Policy) 

16%  Success  Rate  Overall  On  All  FTA  Events 
37%  Success  Rate  On  Out-Of-Area  Events 

Average  MHs  Per  Event 

19  MH  Via  DS 

164  MH  Via  On-Site  Support 

Average  Cost  Per  Event  (Based  on  $60.00  Per  Hour) 

$1,140.00  for  DS 

$9,840.00  Laborand  $5,500.00  Travel  ForOn-Site  ($15,390.00) 

These  methods  generated  faster  response  time 
for  solving  the  system  problem,  as  well  as 
lowering  labor  and  travel  costs.” 

While  that  information  was  more  specific  to  the 
submarine  community,  it  could  be  assumed  that 
based  on  surface  ship  technical  assists  being 
resolved  remotely  by  the  GDSC  vice  having 
deployed  technical  assist  visits  would  result  in 
similar  cost  avoidance  or  savings  for  the  surface 
Fleet  as  well.  These  potential  cost  savings 
would  be  largely  attributed  to  the  DS  enabled 
reduction  of  “Find  Time”  and  the  ability  to 
resolve  issues  remotely. 


DS  can  provide  real  cost  savings,  but  is  DS  used 
by  Sailors  in  the  Fleet?  To  better  understand 
Fleet  DS  usage,  the  authors  requested  a  data  pull 
from  the  DS  CRM  Metrics  database  to  see 
which  surface  commands  used  DS  from  1999  to 
2011.  The  following  table  in  Figure  5  below 
shows  requested  assistance  call  volume  for  the 
GDSC.  While  the  call  volume  data  generated  by 
this  request  was  not  associated  to  cost  in  the 
same  method  as  was  done  by  Guertin  and 
Bruhns  above  for  the  submarine  community,  i.e., 
cost  per  resolved  help  request,  it  can  be  assumed 
that  there  was  some  level  of  savings,  cost  or 
time,  realized  by  the  surface  Fleet  through  DS 
instead  of  through  deployed  assistance. 

DDG  5 1  and  FCS  call  volume  over  the  past  ten 
years  has  been  increasing.  The  DDG  5 1  Class 
had  the  highest  volume  of  requests  as  indicated 
(dark  blue)  and  also  shows  a  general  increase  in 
GDSC  requests.  This  was  expected  since  the 
DDG  5 1  Class  ships  are  also  the  largest 
population  of  surface  ships  in  the  Fleet. 


Year 

Call  Volume 

DDG  51 

LCS 

2002  - 

1,569 

3 

2003  - 

7,159 

3 

2004  - 

10,649 

3 

2005  - 

14,483 

3 

2006  - 

40,187 

22 

2007  - 

41,820 

70 

2008  - 

43,585 

219 

2009  - 

67,965 

2,549 

2010  - 

93,072 

4,540 

2011  - 

80,478 

1,649 

Most  surface  ship  classes  also  generated 
increases  in  GDSC  requests  during  that  same 
period,  although  from  2006  -  2008  call  volume 
was  fairly  consistent.  The  data  named,  “All 
Other”  includes  all  other  surface  ships  not 
specifically  listed,  the  United  States  Coast  Guard 
(USCG)  and  Military  Sealift  Command  (MSC), 
as  well  as  submarine  and  some  non-ship  data.  In 
general,  the  GDSC  is  experiencing  increases  in 
call  volume  each  year,  with  call  volume  in  20 1 0 
approaching  nearly  400,000  requests.  In  the 
Figure  5  below,  year  2011  reflects  partial  year 
data  and  for  most  ships  is  expected  to  surpass 


the  call  volume  of  2010. 


Figure  5  -  Navy  Enterprise  CRM  Call  Volume 
Growth 

(DS  eCRM  Metrics  Data,  2011) 


Extrapolating  from  the  Guertin  and  Bruhns’  data 
described  earlier  with  respect  to  similar  requests, 
as  shown  in  Figure  5  above,  from  surface  fleet 
assets,  can  be  conjectured  that  DS  is  resulting  in 
overall  cost  savings.  This  conjecture  is  based  on 
at  least  two  assumptions,  1)  anecdotal 
information  indicates  that  since  Fleet  Sailors 
repetitively  use  what  works  and  won’t  use  it  if  it 
doesn’t,  then  increases  in  GDSC  requests  may 
indicate  a  correlation  in  the  success  of  problem 
resolution,  and  2)  Navy  leadership  will  not  long 
embrace  or  tolerate  a  process  that  is  not  resulting 
in  success. 

While  there  is  cost  reduction  causality  surmised 
by  the  general  increase  in  GDSC  request  volume 
by  Fleet  assets  shown  above,  the  increase  may 
also  be  related  to  better  Fleet  awareness  of  the 
Chief  of  Naval  Operations  (CNO)  Distance 
Support  Policy  of  22  Mar  2007,  and  the 
guidance  dictated  by  the  Joint  Fleet  Maintenance 
Manual  (JFFM),  both  of  which  requires  the  use 
of  DS  when  organic  efforts  cannot  resolve  a 
problem  or  issue.  There  is  also  some  GDSC  call 
volume  increase  each  year  that  can  be  attributed 
to  the  ongoing  effort  by  the  DS  CRM  team  to 
capture  other  sources  of  “support”  data  into  the 
eCRM  SDE  that  may  not  have  been  included  in 
earlier  year’s  data  and  in  the  case  of  the  DDG  5 1 
data,  a  gradual  increase  in  total  ships  over  the 
10-years.  Regardless,  the  assumption  seems 
valid  that  the  Fleet  is  increasing  its  usage  of  the 
GDSC  to  resolve  issues  and  problems  over 


deploying  assist  visits,  likely  resulting  in  R- 
TOC. 

Conducting  one  or  more  business  case  analysis 
(BCA)  of  surface  unit  cost  savings  resulting 
from  DS  similar  to  the  Guertin  and  Bruhns’  data, 
would  allow  Navy  leadership  and  Program 
Managers  (PMs)  more  precise  information  of 
DS  generated  cost  avoidance  or  savings  that 
could  then  help  justify  (or  not)  increased 
incorporation  of  DS  in  acquisition  programs. 

ISSUES  AND  BARRIERS 

The  authors  believe  the  following  Issues  and 
Barriers  affect  full  incorporation  of  DS  into  the 
Fleet  for  maximum  cost  savings. 

1 )  Inconsistent  definitions  and  application  of 
DS  confuses  what  DS  is  and  how  to  best  use 
it.  Defining  what  DS  currently  provides 
today  and  what  it  needs  to  become 
tomorrow  in  order  to  fully  enable 
operationally-manned  platform  crews  to 
meet  mission  requirements  is  essential.  DS 
over  the  past  1 0  years  has  meant  something 
much  different  to  each  program,  group  or 
user  involved  with  DS.  PMW-240’s  on¬ 
going  Capability-Based  Assessment  (CBA) 
of  DS  will  help  define  a  base-line  for 
distance  support,  as  will  on-going  reviews  of 
Fleet  software  applications  used  to  support 
ship  crews.  Using  common  DS  definitions 
throughout  the  Navy  Enterprise  can  help 
prevent  misinterpretations  of  DS  capability. 

2)  Incorporation  of  DS  ‘Best  Practices”  both 
within  the  Navy,  Department  of  Defense 
(DoD)  and  other  government  organizations 
would  result  in  better  DS.  As  an  example, 
the  Navy  has  expended  hours  and  dollars  on 
Remote  Monitoring  (RM),  which  is  a  real 
capability  that  through  DS  can  result  in 
significant  savings.  Flowever,  the  Navy  still 
doesn’t  have  a  seamless  and  fully  automated 
RM  capability  that  works  across  most 
platforms.  At  the  same  time,  the  auto 
industry  has  embraced  RM  and  predictive 
modeling  to  actually  realize  reduced  “Find 
Time”  for  issues  and  problems,  e.g., 


OnStar™.  While  a  modem  warship  is 
infinitely  more  complicated  than  a  car  or 
truck,  the  auto  industry  concept  seems 
expandable,  especially  since  new  ships  like 
the  DDG  1000  have  upwards  of  30,000+ 
sensor  outputs  available  for  capturing 
equipment  and  system  health. 

3)  Promoting  open  discussions  of  DS 
throughout  the  Navy,  actively  bringing  in 
infomiation  about  other  DoD,  contractor  and 
organization’s  DS  successes  is  required  for 
Navy  DS  implementation  as  needed  for  an 
affordable  3 13-ship  Navy.  By  ensuring  DS 
process  and  application  status  transparency, 
common  definitions  and  shared  lesson 
learned,  DS  can  transform  the  Fleet 
workforce  and  reduce  total  ownership  cost. 
Yet  where  are  the  DS  conferences  and 
symposium  discussions  that  provide  the 
acquisition  community  open  information 
about  DS  processes  and  applications  across 
the  Fleet?  Sharing  of  DS  “Best  Practices” 
seems  isolated  to  small  disparate 
organizations  within  the  Navy  Enterprise. 
Although  currently  under  revision,  the  DS 
CRM  team  maintains  a  DS  website  that 
would  be  an  ideal  repository  of  DS  MW  A 
infomiation,  comments  and  lessons  learned, 
or  if  not  at  that  site  then  on  a  site  like  the 
USFFC  website.  Regardless  of  where  the 
data  is  held,  there  needs  to  be  open 
discussions  and  a  common  data  repository 
so  that  PMs  and  their  staff  can  leam, 
discuss,  ask  about  effective  DS  MW  A. 
Learning  what  DS  processes  work  well  to 
move  workload  ashore  and  ensuring 
everyone  understands  any  planned  changes 
to  DS  applications  will  help  PMs  and  their 
staff  better  implement  viable  DS  within  the 
various  Navy  programs. 

4)  Not  fully  embracing  the  concept  of  DS  into 
a  ship  acquisition  process.  If  the  Navy  is  to 
fully  realize  the  CNO’s  vision  of  DS  as  an 
optimizer  of  organic  and  shore  infrastructure 
at  the  lowest  TOC,  then  throughout  Navy 
acquisition,  DS  should  be  integrated  into 
various  disciplines  of  systems  engineering 
for  influence  of  system  design,  starting  at 
the  earliest  phase  of  acquisition.  Navy  DS  is 


part  of  the  system  design  and  as  such, 
human  capital  and  supportability 
requirements  that  mitigate  shipboard 
workload  must  be  addressed  concurrently 
with  other  system  performance  and  design 
requirements. 

5)  Organizational  parochialism  prevents 
sharing  of  DS  success.  Unfortunately,  an 
often  inherent  issue  of  business  processes 
within  large  organizations  is  the  tendency  to 
hold  close  information  that  provides  success 
within  that  organization.  Often  this  “helps” 
those  organizations  improve  funding  for 
programs,  etc.;  however,  this  may  not  be  the 
best  course  of  action  for  robust 
implementation  of  DS  throughout  the  Navy 
Enterprise.  Because  of  a  lack  of  awareness 
of  DS  processes  and  applications,  other 
programs  “re-invent”  processes  or  develop 
similar  applications,  wasting  funding,  or 
continue  modifying  outdated  or  work 
intensive  processes  or  applications  in  a 
shortsighted  “rice-bowl”  approach. 

6)  Not  fully  implementing  planned  DS  design 
features  or  making  erroneous  assumptions 
about  DS,  increases  risk  to  the  success  of 
new  acquisitions,  e.g.,  the  DDG  1000.  The 
DDG  1000  Class  design  had  extensive 
Eluman  Systems  Integration  (HSI)  studies  to 
account  for  every  minute  of  each  Sailor’s 
tasking  by  billet.  These  studies  were 
validated  by  testing  and  design  models.  At 
the  same  time,  DDG  1 000  designers  made 
assumptions  about  what  DS  processes  or 
applications  would  be  available  and  needed 
to  move  workload  ashore  or  reduce  organic 
workload  through  automation  for  the  HSI 
validated  manning.  In  some  cases  these 
design  assumptions  were  made  based  on  an 
incomplete  understanding  of  what  DS  would 
be  able  to  provide,  or  on  stated  technology 
application  capability  that  later  failed  to  be 
realized.  These  designers  assumed  or  were 
told  that  technology  would  be  developed  for 
DDG  1 000  reducing  cognitive  and  physical 
workloads  of  the  crew  using  DS  automation 
and  simplification.  However,  possibly 
starting  in  the  Engineering  &  Manufacturing 
Development  (E&MD)  phase,  as  funding 


constraints  were  factored  into  the  overall 
Navy  budget,  critical  DS  features  were  put 
on  hold,  cut  or  not  available,  e.g.,  Enterprise 
Remote  Monitoring  (eRM)  and  Navy  Cash. 
In  each  case,  further  analysis  of  workload 
impact  will  have  to  be  made  in  order  to 
prevent  overburdening  of  crew.  For  some 
applications,  such  as  eRM,  existing  systems 
like  the  ICAS  may  work  in  a  similar  fashion 
without  undue  or  adverse  impact  to  the 
ship’s  workload,  while  others,  like  Navy 
Cash,  do  not  have  an  immediate  solution  and 
are  requiring  development  of  a  new 
application  for  use  on  DDG  1000  ships. 
While  through  great  effort  by  the  DDG  1 000 
PM’s  team  to  incorporate  work-around 
processes  and  technology  mitigates  some  of 
the  risk,  in  the  case  of  the  DDG  1000,  it 
shows  how  assumptions  made  early  in 
acquisition  stages  about  the  transition  of  DS 
applications  from  Technology  Readiness 
Level  (TRL)  1  to  TRL  9  is  challenging.  The 
lessons  learned  and  critical  to  successful 
design  is  to  have  program  acquisition 
professionals  fully  understand  DS  process 
and  application  maturity  before  making 
assumptions  of  a  capability  that  may  not  be 
founded  on  firm  understanding  of  the  DS 
application  TRL. 

7)  Budget  constraints  may  force  PMs  to  cut  DS 
related  expenditures  in  their  program.  PMs 
and  others,  both  in  programs  and  sponsor 
organizations  may,  without  fully 
understanding  the  interdependencies  of  DS 
processes  and  technology  as  they  relate  to 
enabling  DS  MWA,  curtail  or  cut  the  final 
development  or  implementation  of 
capability  needed  to  fully  enable  a  DS 
process  or  application.  Often  these  cuts  are 
done  for  the  right  reason,  such  as  cost  over 
runs  due  to  lack  of  software  rigor  by  the 
contractor,  budget  cuts,  etc.,  but  the  effect 
still  reduces  the  overall  platform  DS 
capability. 
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Figure  6  -  Notional  DS  Systems  Engineering 

Approach 

(DS  CRM,  Draft  Acquisition  Guide  for  Program 

Managers 

Ensuring  each  program  has  a  person 
assigned  responsibility  as  DS  Integrator  may 
mitigate  adverse  impact  on  the  program. 

This  DS  Integrator  would  understand  and 
keep  key  program  personnel  informed  of 
potential  impact  when  modifications  are 
made  in  one  or  more  implementation  area  of 
a  DS  MWA  process  or  application.  At  the 
very  least,  PMs  should  attempt  to  codify 
well  understood  ground  rules  and 
assumptions  in  the  Technology 
Development  (TD)  phase  and  use  a  systems 
engineering  (SE)  approach  (similar  to  Figure 
6  above)  to  help  understand  ramifications 
for  deleting  DS.  For  example,  if  a  platform 
design  has  included  a  robust  capability  to 
use  sensor  data  that  can  be  sent 
automatically  off  platform,  allowing 
performance  of  predictive  assessments  for 
maintenance,  or  has  fully  networked  DS 
dependent  work  applications  required  to 
push  work  off-platform  and,  through  budget 
constraints,  these  capabilities  are  reduced  or 
cut,  it  may  adversely  impact  the  platform’s 
manning  posture.  This  also  may  result  in 
maintenance,  admin  and  supply  functional 
crew  increases  as  off-platform  data  is  no 
longer  available  automatically  and  requires 
human  intervention  to  process. 


All  of  these  may  have  an  unforeseen,  but 
adverse  affect  on  the  crew  after  Initial 
Operational  Capability  (IOC).  Sailors  will  strive 
in  most  cases  to  “make  it  work”  regardless,  but 
without  initially  planned  DS  enabling  processes 
and  applications,  the  Sailors  often  end  up  with 
significant  “quality  of  life”  impacts,  as  they 
work  longer  hours  with  less  resources  to  keep 
meeting  command  mission  requirements. 

CONCLUSION 

After  nearly  10-years  of  DS  growth  and 
improvement,  there  seems  to  be  connecting 
indicators  that  DS  will  result  in  R-TOC.  In 
some  cases  cost  saving  have  been  identified, 
e.g.,  submarine  business  case  analysis  (BCA) 
described  previously,  and  in  other  cases  it  is 
inferred  based  on  increasing  GDSC  usage 
figures. 

However,  there  remains  significant  room  for 
further  growth  and  improvement  of  DS 
implementation.  The  use  of  existing  DS 
infrastructure,  policies,  applications  and 
processes,  combined  with  development  of  new 
DS  procedures  and  processes  will  provide 
improved  life  cycle  support  to  ships  like  the 
LCS  and  DDG  1000  Class  ships  and  other  new 
ship  acquisitions.  Viable,  realistic  and 
customer-focused  DS  will  enable  overall 
reduction  of  manning  and  logistics  footprint  to 
R-TOC.  In  many  cases  these  DS  improvements 
can  be  retro-fitted  to  serve  legacy  platforms. 

Incorporating  DS  applications  and  processes  for 
new  acquisition  and  legacy  ships  and  platforms 
cannot  be  a  piecemeal  process  conducted  by 
disparate  organizations,  each  trying  to  field  their 
latest  application  capability.  Nor  can  PMs 
overlook  the  inter-dependencies  of  DS  processes 
and  applications,  as  they  relate  to  manning, 
logistics  support  and  quality  of  life.  Using  a 
System  Engineering  approach  to  DS  in  order  to 
interpret  the  user  needs,  develop  a  viable  and 
affordable  solution,  assess  and  test  the  solution 
E2E  prior  to  delivery  is  critical  to  the  continued 
success  and  to  fully  realize  potential  total 
ownership  cost  reductions  due  to  DS 
implementation. 


Recommendations  /  Way  Ahead  for 
Distance  Support 

•  Conduct  one  or  more  business  case 
analysis  (BCA)  to  determine  expected 
surface  unit  cost  savings  resulting  from 
DS.  Promulgate  the  resultant  BCA 
information  to  the  Navy  acquisition 
community  and  acquisition  sponsors. 

•  Fully  integrate  DS  throughout 
acquisition  phases  to  effectively  use  the 
technologies  and  processes  employed 
through  platform-to-platform,  platform- 
to-shore  and  shore -to-shore  relationships 
(Figure  7  below). 

•  Continue  to  apply  rigorous  business 
rules  to  processes  used  to  minimize 
manpower  and  workload  wherever 
possible. 

•  Treat  DS  processes  and  applications  just 
as  other  key  elements  of  the  acquisition 
process. 

•  Update  and  embellish  the  Defense 
Acquisition  University  (DAU) 
curriculum  with  viable  approaches  to 
DS  within  the  DoD  acquisition  process. 
Provide  and  require  DS  specific 
acquisition  course-work  for  acquisition 
professionals. 

•  Establish  and  promote  the  concept  of  a 
Defense  Acquisition  Workforce 
Improvement  Act  (DAWIA)  DS 
process,  either  stand-alone  or 
incorporated  throughout  the  acquisition 
communities. 

•  Ensure  DS  is  implemented  from  a 
systems  engineering  approach,  funded 
and  tested  as  appropriate  in  each  stage 
of  the  acquisition  processes,  i.e., 
included  in  a  program  Test  and 
Evaluation  Master  Plan  (TEMP)  will 
help  ensure  a  viable  DS  capability  is 
delivered. 

•  Accelerate  the  consolidation  of 
duplicate  Help  Desk  and  Call  Centers 
under  the  single  GDSC  structure  will 
provide  immediate  additional  cost 
savings  and  streamline  data  collection 
for  KM. 


•  Promote  on-going  academic  studies  of 
Navy  DS  from  various  business, 
logistics  and  technology  perspectives  at 
locations  like  the  Naval  Postgraduate 
School  (NPS),  and  ensure  widest 
dissemination  of  resulting  thesis  from 
these  academic  studies  throughout  the 
Navy  Acquisition  and  DS  communities. 

•  Map  the  DS  value  streams,  beginning 
with  the  current  process  state  of  how 
work  and  information  flow  now,  then 
drawing  a  leaner  future  state  of  how 
they  should  flow  and  creating  an 
implementation  plan  with  timetable 
would  help  refine  the  DS  MWA 
processes  for  further  cost  savings. 
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Figure  7  -  DS  in  the  Acquisition  Process 

(DS  CRM,  Draft  Acquisition  Guide  for  Program 
Managers 


Operationally-manned  systems,  platforms  and 
ultimately  shore -bases  will  require  efficient 
routine  business  processes,  using  automation 
and  technology  when  and  where  appropriate. 

DS  currently  provides  enhanced  capabilities  in 
pay  and  personnel,  logistics  management, 
training,  technical  support,  medical  services  and 
other  reach-back  capabilities.  The  efforts 
described  above  and  others  will  in  turn  allow 
better  realization  of  manning  reductions,  shore 
support  logistics  footprint  reductions. 

The  DS  CRM  team  has  developed  a 
comprehensive  draft  DS  Acquisition  Guide  for 
Program  Managers  to  use  in  all  phases  of  the 
acquisition  program.  This  guide  details  what  DS 
should  be  considered  prior  to  moving  forward 


with  acquisition  design  phases  and  to  ensure 
Acquisition  Program  Managers  are  aware  and 
use  existing  CRM  solutions  vice  re-inventing 
processes  and  applications.  This  guide  has  not 
yet  been  fully  reviewed  and  accepted,  nor  has  it 
been  promulgated  for  use,  but  it  is  a  very  good 
first  start  on  codifying  and  defining  what  steps 
are  needed  to  fully  incorporate  viable  distance 
support  in  an  acquisition  program  and  enable 
reduced  Total  Ownership  Cost  (TOC). 

Acquisition  Program  Managers  must  analyze 
and  integrate  DS  capabilities  from  the  inception 
of  system  design  through  and  beyond  delivery  to 
the  greatest  extent  possible,  providing  real  time 
assistance,  logistics,  maintenance  and 
Manpower,  Personnel,  Training  &  Education 
(MPT&E)  support  to  operational  units. 

The  following  paragraphs  provide  some  of  the 
possible  DS  recommendations  for  PMs  to 
consider  and  use  to  update  acquisition 
documentation  and  incorporate  DS  language  into 
their  processes. 

ACQUISITION  DOCUMENTATION 
LANGUAGE  EXAMPLES 

The  authors  offer  the  following  examples  of  how 
documentation  can  be  revised  to  better  codify 
DS  throughout  the  acquisition  process.  These 
examples  were  derived  from  the  draft  DS 
Acquisition  Guide  for  Program  Managers 
currently  under  development  by  the  DS  CRM 
team. 

Acquisition  Strategy  (AS):  The  following  language 
or  similar  language  can  be  used  to  address  DS  in  a 
program  AS: 

“Support  Strategy:  The _ program 

support  strategy  provides  for  long-term,  “cradle  to 
grave”  total  life  cycle  support  for  all  fielded  weapons 
systems.  Navy  DS  will  be  part  of  this  strategy  so  that 
total  ownership  costs  and  logistics  footprint 
considerations  can  be  addressed  early  in  the 

_ program’s  life.  Communication  will 

be  established  with  the  Navy  Enterprise  Help 
Desk/Global  Distance  Support  Center.  Program 
technical,  support  product  and  SME  information  will 


be  provided  to  the  DS  organization  to  facilitate 
effective,  efficient  Fleet  customer  service.” 

Navy  Training  Systems  Plan  (NTSP):  The 
following  language  or  similar  language  can  be  used 
in  the  most  suitable  areas  of  the  program’s  NTSP 
Section  l.H  CONCEPTS: 

“The _ program  will  utilize  the  Navy 

Global  Distance  Support  Center  (GDSC)  Help  Desk 
as  the  initial  point  of  contact  to  respond  to  Fleet 
requests  for  manpower,  personnel,  training  and 

education  assistance.  The _ program 

In  Service  Engineering  Agent  (ISEA), 

_ Code _ will  be 

identified  in  the  GDSC  Customer  Relationship 
Management  (CRM)  database  as  the  technical  subject 
matter  expert  to  respond  to  all  Fleet  operator  and 
maintainer  queries  on  the  above  topics.” 

Integrated  Logistics  Support  Plan  (ILSP):  The 

following  language  or  similar  language  can  be  used 
to  address  DS  in  a  program  ILSP: 

“The _ program  will  utilize  the  Navy 

Global  Distance  Support  Center  (GDSC)  Help  Desk 
as  the  initial  point  of  contact  to  respond  to  Fleet 
requests  for  sustainment  support  in  the  areas  of 
supply  support,  training,  maintenance  and 

documentation.  The _ program  In 

Service  Engineering  Agent  (ISEA), 

_ Code _ will  be 

identified  in  the  GDSC  Customer  Relationship 
Management  (CRM)  database  as  the  technical  subject 
matter  expert  (SME)  to  respond  to  all  Fleet  operator 
and  maintainer  queries.” 

Users  Logistics  Support  Summary  (ULSS):  The 

following  language  or  similar  language  can  be  used 
to  address  DS  in  a  program  ULSS: 

“The _ program  will  utilize  the  Navy 

Global  Distance  Support  Center  (GDSC)  Help  Desk 
as  the  initial  point  of  contact  to  respond  to  Fleet 
requests  for  sustainment  support  in  the  areas  of 
supply  support,  training,  maintenance  and 
documentation.  The  GDSC  Phone  number  is 

_ ;  Email  is 

_ .  The 

_ program  In  Service  Engineering 

Agent  (ISEA), _ ,  Code 

_ ,  Phone _ ,  Email 

_ will  be  identified  in  the  GDSC 

Customer  Relationship  Management  (CRM)  database 


as  the  technical  subject  matter  expert  to  respond  to  all 
Fleet  operator  and  maintainer  queries.” 
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the  warfighter  /  maintainer,  as  well  as  provide  a 
platform  to  use  telecommunication  (remote 
diagnostic  support,  help  desk  operations, 
condition  /  case-based  maintenance, 
collaboration,  and  interactive  electronic 
technical  manuals  (TMs).  The  JDSR  ACTD  was 
the  predecessor  development  for  the  Navy 
Information  Application  Product  Suite  (NIAPS). 
As  a  NIAPS  subject  matter  expert,  he  currently 
manages  and  oversees  all  DS  NIAPS  special 
platform  initiatives,  including  LCS,  DDG 1000, 
Aegis  Ashore,  Military  Sealift  Command,  as  well 
as  others  platforms  as  needed.  He  also 
participates  in  development  and  technology > 


insertion  projects  and  is  primary  lead  for  the 
Distance  Support  Afloat  Portal,  which  resides 
on  NIAPS.  Mr.  Jones  is  a  Microsoft  Certified 
Professional  (MCP)  as  well  as  COMPTIA 
Security  +  Certified. 


